[[mvc-viewresolver]]
= View Resolution

[.small]#xref:web/webflux/dispatcher-handler.adoc#webflux-viewresolution[See equivalent in the Reactive stack]#

Spring MVC defines the `ViewResolver` and `View` interfaces that let you render
models in a browser without tying you to a specific view technology. `ViewResolver`
provides a mapping between view names and actual views. `View` addresses the preparation
of data before handing over to a specific view technology.

The following table provides more details on the `ViewResolver` hierarchy:

[[mvc-view-resolvers-tbl]]
.ViewResolver implementations
|===
| ViewResolver| Description

| `AbstractCachingViewResolver`
| Subclasses of `AbstractCachingViewResolver` cache view instances that they resolve.
  Caching improves performance of certain view technologies. You can turn off the
  cache by setting the `cache` property to `false`. Furthermore, if you must refresh
  a certain view at runtime (for example, when a FreeMarker template is modified),
  you can use the `removeFromCache(String viewName, Locale loc)` method.

| `UrlBasedViewResolver`
| Simple implementation of the `ViewResolver` interface that effects the direct
  resolution of logical view names to URLs without an explicit mapping definition.
  This is appropriate if your logical names match the names of your view resources
  in a straightforward manner, without the need for arbitrary mappings.

| `InternalResourceViewResolver`
| Convenient subclass of `UrlBasedViewResolver` that supports `InternalResourceView` (in
  effect, Servlets and JSPs) and subclasses such as `JstlView`. You can specify the view
  class for all views generated by this resolver by using `setViewClass(..)`.
  See the {spring-framework-api}/web/reactive/result/view/UrlBasedViewResolver.html[`UrlBasedViewResolver`]
  javadoc for details.

| `FreeMarkerViewResolver`
| Convenient subclass of `UrlBasedViewResolver` that supports `FreeMarkerView` and
  custom subclasses of them.

| `ContentNegotiatingViewResolver`
| Implementation of the `ViewResolver` interface that resolves a view based on the
  request file name or `Accept` header. See xref:web/webmvc/mvc-servlet/viewresolver.adoc#mvc-multiple-representations[Content Negotiation].

| `BeanNameViewResolver`
| Implementation of the `ViewResolver` interface that interprets a view name as a
  bean name in the current application context. This is a very flexible variant which
  allows for mixing and matching different view types based on distinct view names.
  Each such `View` can be defined as a bean e.g. in XML or in configuration classes.
|===


[[mvc-viewresolver-handling]]
== Handling
[.small]#xref:web/webflux/dispatcher-handler.adoc#webflux-viewresolution-handling[See equivalent in the Reactive stack]#

You can chain view resolvers by declaring more than one resolver bean and, if necessary, by
setting the `order` property to specify ordering. Remember, the higher the order property,
the later the view resolver is positioned in the chain.

The contract of a `ViewResolver` specifies that it can return null to indicate that the
view could not be found. However, in the case of JSPs and `InternalResourceViewResolver`,
the only way to figure out if a JSP exists is to perform a dispatch through
`RequestDispatcher`. Therefore, you must always configure an `InternalResourceViewResolver`
to be last in the overall order of view resolvers.

Configuring view resolution is as simple as adding `ViewResolver` beans to your Spring
configuration. The xref:web/webmvc/mvc-config.adoc[MVC Config] provides a dedicated configuration API for
xref:web/webmvc/mvc-config/view-resolvers.adoc[View Resolvers] and for adding logic-less
xref:web/webmvc/mvc-config/view-controller.adoc[View Controllers] which are useful for HTML template
rendering without controller logic.


[[mvc-redirecting-redirect-prefix]]
== Redirecting
[.small]#xref:web/webflux/dispatcher-handler.adoc#webflux-redirecting-redirect-prefix[See equivalent in the Reactive stack]#

The special `redirect:` prefix in a view name lets you perform a redirect. The
`UrlBasedViewResolver` (and its subclasses) recognize this as an instruction that a
redirect is needed. The rest of the view name is the redirect URL.

The net effect is the same as if the controller had returned a `RedirectView`, but now
the controller itself can operate in terms of logical view names. A logical view
name (such as `redirect:/myapp/some/resource`) redirects relative to the current
Servlet context, while a name such as `redirect:https://myhost.com/some/arbitrary/path`
redirects to an absolute URL.


[[mvc-redirecting-forward-prefix]]
== Forwarding

You can also use a special `forward:` prefix for view names that are
ultimately resolved by `UrlBasedViewResolver` and subclasses. This creates an
`InternalResourceView`, which does a `RequestDispatcher.forward()`.
Therefore, this prefix is not useful with `InternalResourceViewResolver` and
`InternalResourceView` (for JSPs), but it can be helpful if you use another view
technology but still want to force a forward of a resource to be handled by the
Servlet/JSP engine. Note that you may also chain multiple view resolvers, instead.


[[mvc-multiple-representations]]
== Content Negotiation
[.small]#xref:web/webflux/dispatcher-handler.adoc#webflux-multiple-representations[See equivalent in the Reactive stack]#

{spring-framework-api}/web/servlet/view/ContentNegotiatingViewResolver.html[`ContentNegotiatingViewResolver`]
does not resolve views itself but rather delegates
to other view resolvers and selects the view that resembles the representation requested
by the client. The representation can be determined from the `Accept` header or from a
query parameter (for example, `"/path?format=pdf"`).

The `ContentNegotiatingViewResolver` selects an appropriate `View` to handle the request
by comparing the request media types with the media type (also known as
`Content-Type`) supported by the `View` associated with each of its `ViewResolvers`. The
first `View` in the list that has a compatible `Content-Type` returns the representation
to the client. If a compatible view cannot be supplied by the `ViewResolver` chain,
the list of views specified through the `DefaultViews` property is consulted. This
latter option is appropriate for singleton `Views` that can render an appropriate
representation of the current resource regardless of the logical view name. The `Accept`
header can include wildcards (for example `text/{asterisk}`), in which case a `View` whose
`Content-Type` is `text/xml` is a compatible match.

See xref:web/webmvc/mvc-config/view-resolvers.adoc[View Resolvers] under xref:web/webmvc/mvc-config.adoc[MVC Config] for configuration details.



